Configuring Chassis for Mobility Unified Reporting System

Configuring Chassis for Mobility Unified Reporting System
 
This chapter describes the configurations required to source data for the MUR application.
Important: These configurations are on the chassis.
For more information on ECS configurations, see the Enhanced Charging Services Administration Guide.
This chapter describes the following topics:
•
Initial Configuration
•
Configuration
Initial Configuration
If the configurations described in this section are not already available on the system, these must be configured.
Initial configuration steps:
Step 1
Ensure that ECS license is installed on the system.
Step 2
Create the ECS administrative user account as described in the Creating the ECS Administrative User Account section.
Step 3
Enable Active Charging as described in the Enabling Active Charging section.
Step 4
Create Active Charging Service as described in the Creating the Active Charging Service section.
Step 5
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Installing the ECS License
To enable and configure ECS functionality on the system you must obtain and install one of the following licenses:
•
Starent P/N: 600-00-7526 Enhanced Charging Bundle 1 1k Sessions license / Cisco PID: ASR5K-00-CS01ECG1 Enhanced Charging Bundle 1 1k Sessions license
•
Starent P/N: 600-00-7574 Enhanced Charging Bundle 2 1k Sessions license / Cisco PID: ASR5K-00-CS01ECG2 Enhanced Charging Bundle 2 1k Sessions license — to enable and configure Diameter and DCCA functionality with ECS
For information on how to install the licenses, see the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Creating the ECS Administrative User Account
At least one administrative user account that has ECS functionality privileges must be configured on the system. This is the account that is used to log on and execute ECS-related commands. For security purposes, it is recommended that these user accounts be created along with general system functionality administration.
Use the following configuration example to create the ECS Administrative user account:
configure
  context local
     administrator <user_name> password <password> ecs
     end
Notes:
•
Aside from having ECS capabilities, an ECS Administrator account also has the same capabilities and privileges as any other system-level administrator account.
•
You can also create system ECS user account for a config-administrator, operator, or inspector. ECS accounts have all the same system-level privileges of normal system accounts except that they have full ECS command execution capability. For example, an ECS has rights to execute every command that a regular administrator can in addition to all of the ECS commands.
•
Note that only Administrator and Config-administrator-level users can provision ECS functionality. Refer to the Configuring System Settings chapter of the System Administration Guide for additional information on administrative user privileges.
Enabling Active Charging
Active Charging must be enabled before configuring charging services.
Use the following configuration example to enable Active Charging:
configure
  require active-charging
     context local
     interface <interface_name>
        ip address <ipv4/ipv6_address> <ipv4/ipv6_address/mask>
        exit
     server ftpd
     end
For more information, refer to the Enhanced Charging Services Administration Guide.
Creating the Active Charging Service
Use the following configuration example to create an Active Charging Service:
configure
  active-charging service <service_name> [ -noconfirm ]
  end
Configuration
The following is the sequence of configurations necessary to source data to the MUR application:
Step 1
Activate P2P analyzer as described in the Activating P2P Analyzer section.
Step 2
Configure EDR flow format as described in the Configuring the EDR Flow Format section.
Step 3
Configure routing ruledefs and rulebase for deep-packet inspection as described in the Configuring Deep Packet Inspection section.
Step 4
Optional. Configure Smartphone tethering detection feature as described in the Configuring Tethering Detection Feature section.
Step 5
Configure EDR module as described in the EDR Module Configuration section.
Step 6
Configure user as described in the Configuring EDR Download Permission section.
Step 7
Configure the bulkstat schemas and then load it onto the gateway.
Step 8
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Activating P2P Analyzer
Use the following configuration example to activate P2P protocol detection:
configure
  active-charging service <service_name>
    p2p-detection protocol all
    rulebase <rulebase_name>
      p2p dynamic-flow-detection
      end
Notes:
•
P2P protocol detection must be activated only within rulebases used by the APNs for which P2P detection is applicable. P2P detection must not be applied to the rulebases used for APNs where such reporting is either not useful or is not possible.
Configuring the EDR Flow Format
Use the following configuration example to configure the EDR format generated for flows:
configure
  active-charging service <service_name>
    edr-format <edr_format_name> [ -noconfirm ]
      attribute <attribute> { [ format { MM/DD/YY-HH:MM:SS | MM/DD/YYYY-HH:MM:SS | YYYY/MM/DD-HH:MM:SS | YYYYMMDDHHMMSS | seconds } ] [ localtime ] | [ { ip | tcp } { bytes | pkts } { downlink | uplink } ] priority <priority> }
      rule-variable <protocol> <rule> priority <priority>
      rule-variable traffic-type priority <priority>
      rule-variable voip-duration priority <priority>
      event-label <event-label> priority <priority>
      end
Notes:
•
The rule-variable traffic-type and rule-variable voip-duration keywords must be configured to enable voice-call-duration (VCD) based reporting.
•
p2p-protocol is a mandatory field in a flow-edr configurations. However, this field cannot be added to the edr-format configuration unless P2P is licensed. Contact your local Sales or Support representative for information on how to obtain a license.
•
For information on EDR format configuration and rule variables, refer to the EDR Format Configuration Mode Commands chapter of the Command Line Interface Reference.
The following is a sample flow end EDR configuration.
configure
  active-charging service ecs_svc1
    edr-format edr_flow_format
      attribute sn-start-time format seconds priority 10
      attribute sn-end-time format seconds priority 20
      attribute radius-calling-station-id priority 30
      rule-variable ip server-ip-address priority 60
      attribute sn-server-port priority 70
      attribute sn-app-protocol priority 80
      attribute sn-parent-protocol priority 81
      rule-variable ip protocol priority 82
      rule-variable p2p protocol priority 90
      attribute sn-volume-amt ip bytes uplink priority 100
      attribute sn-volume-amt ip bytes downlink priority 110
      attribute sn-volume-amt ip pkts uplink priority 120
      attribute sn-volume-amt ip pkts downlink priority 130
      rule-variable bearer 3gpp charging-id priority 140
      rule-variable bearer 3gpp imei priority 141
      rule-variable bearer 3gpp rat-type priority 142
      rule-variable bearer 3gpp user-location-information priority 143
      rule-variable traffic-type priority 160
      rule-variable voip-duration priority 170
      end
The following is a sample HTTP EDR configuration.
configure
  active-charging service ecs_svc1
    edr-format edr_http_format
      attribute sn-start-time format seconds priority 10
      attribute sn-end-time format seconds priority 20
      attribute radius-calling-station-id priority 30
      rule-variable ip server-ip-address priority 50
      rule-variable http host priority 70
      rule-variable http content type priority 80
      attribute transaction-downlink-bytes priority 90
      attribute transaction-uplink-bytes priority 100
      attribute transaction-downlink-packets priority 110
      attribute transaction-uplink-packets priority 120
      rule-variable bearer 3gpp charging-id priority 130
      end
Verifying your Configuration
To verify your configuration, in the Exec Mode, enter the following command:
show active-charging edr-format name <edr_format_name>
Configuring Deep Packet Inspection
This section provides the example configurations that are required for deep packet inspection.
Configuring Routing Rule Definition
Use the following configuration example to create and configure a routing ruledef:
configure
  active-charging service <service_name>
    ruledef <ruledef_name>
      <protocol> <expression> <operator> <condition>
        rule-application routing
        end
Notes:
•
The rule-application routing command specifies the ruledef type. If not specified, by default, the system configures the ruledef as a charging ruledef.
•
For information on all the protocol types, expressions, operators, and conditions supported, refer to the Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.
•
Up to 10 rule matches can be configured in one ruledef.
•
MMS rules must be set appropriately and MMS should be activated at ECS to support MMS reporting in MUR.
The following is a sample ruledef configuration.
configure
   active-charging service srv1
      ruledef http_anymatch
      http any-match = TRUE
      exit
      ruledef icmp_anymatch
      icmp any-match = TRUE
      exit
      ruledef ip_anymatch
      ip any-match = TRUE
      exit
      ruledef mms_anymatch
      mms any-match = TRUE
      exit
      ruledef rr_http_80
      tcp either-port = 80
      rule-application routing
      exit
      ruledef rr_http_8080
      tcp either-port = 8080
      rule-application routing
      exit
      ruledef rr_mms_http_ct
      http content type = application/vnd.wap.mms-message
      rule-application routing
      exit
      ruledef rr_mms_http_url
      http url ends-with .mms
      rule-application routing
      exit
      ruledef rr_mms_wsp_ct
      wsp content type = application/vnd.wap.mms-message
      rule-application routing
      exit
      ruledef rr_mms_wsp_ct_uri
      rule-application routing
      exit
      ruledef rr_mms_wsp_url
      wsp url ends-with .mms
      rule-application routing
      exit
      ruledef rr_wsp_cl_dst_port
      udp dst-port = 9200
      rule-application routing
      exit
      ruledef rr_wsp_cl_src_port
      udp src-port = 9200
      rule-application routing
      exit
      ruledef rr_wsp_co_dst_port
      udp dst-port = 9201
      rule-application routing
      exit
      ruledef rr_wsp_co_src_port
      udp src-port = 9201
      rule-application routing
      exit
      end
Verifying your Configuration
To verify your configuration, in the Exec Mode, enter the following command:
show active-charging ruledef routing
Configuring Rulebase
Use the following configuration example to route traffic to the appropriate analyzer within each rulebase where the reporting is applicable.
configure
  active-charging service <service_name>
    rulebase <rulebase_name> [ -noconfirm ]
      route priority <priority> ruledef <ruledef_name> analyzer <analyzer> [ description ]
      rtp dynamic-flow-detection
      flow end-condition handoff timeout normal-end-signaling session-end [ charging-edr | edr | reporting-edr edr_format_name ]
edr transaction-complete http [ charging-edr | edr-format | reporting-edr edr_format_name ]
      end
Notes:
•
charging-edr will be used as the default option in the flow end-condition and edr transaction-complete command configurations.
•
The edr and edr-format options are available only in 12.1 and earlier releases. In 12.2 and later releases, these options are deprecated and are replaced by the charging-edr option.
•
For MUR reporting needs, use the reporting-edr keyword in the rulebase configuration.
The following is a sample rulebase configuration for reporting EDRs.
configure
  active-charging service ecs_svc1
    rulebase p2p-rb
      flow end-condition handoff timeout normal-end-signaling session-end reporting-edr edr_flow_format
      action priority 4 ruledef rtsp_setup charging-action standard
      action priority 5 ruledef rtsp_play charging-action standard
      action priority 6 ruledef rtsp_teardown charging-action standard
      action priority 7 ruledef rtsp_anymatch charging-action standard
      action priority 10 ruledef sip_anymatch charging-action handshake
      action priority 11 ruledef rtp_anymatch charging-action handshake
      action priority 12 ruledef udp_anymatch charging-action handshake
      action priority 13 ruledef tcp_anymatch charging-action handshake
      action priority 16 ruledef mms_anymatch charging-action policy1
      action priority 60 ruledef http_anymatch charging-action standard
      action priority 95 ruledef udp_anymatch charging-action standard
      action priority 99 ruledef icmp_anymatch charging-action standard
      action priority 100 ruledef ip_anymatch charging-action handshake
      action priority 990 ruledef tcp_anymatch charging-action standard
      action priority 1000 ruledef ip_anymatch charging-action standard
      route priority 1 ruledef rr_wsp_co_src_port analyzer wsp-connection-oriented
      route priority 2 ruledef rr_wsp_co_dst_port analyzer wsp-connection-oriented
      route priority 3 ruledef rr_wsp_cl_src_port analyzer wsp-connection-less
      route priority 4 ruledef rr_wsp_cl_dst_port analyzer wsp-connection-less
      route priority 5 ruledef rr_http_80 analyzer http
      route priority 6 ruledef rr_http_8080 analyzer http
      route priority 7 ruledef rr_mms_http_ct analyzer mms
      route priority 8 ruledef rr_mms_http_url analyzer mms
      route priority 9 ruledef rr_mms_wsp_ct analyzer mms
      route priority 10 ruledef rr_mms_wsp_url analyzer mms
      route priority 11 ruledef rr_mms_wsp_ct_uri analyzer mms
      route priority 60 ruledef sip_src analyzer sip
      route priority 65 ruledef sip_dst analyzer sip
      route priority 70 ruledef rtsp_src analyzer rtsp
      route priority 75 ruledef rtsp_dst analyzer rtsp
      route priority 250 ruledef sdp_route analyzer sdp
      rtp dynamic-flow-detection
      edr transaction-complete http reporting-edr edr_http_format
      edr voip-call-end reporting-edr edr_flow_format
      udr threshold interval 60
      udr threshold volume total 100000
      p2p dynamic-flow-detection
      end
Verifying your Configuration
To verify your configuration, in the Exec Mode, enter the following command:
show active-charging rulebase name <rulebase_name>
Configuring Charging Action
Use the following configuration example to configure a charging action:
configure
  active-charging service <service_name>
    charging-action <charging_action_name> [ -noconfirm ]
      content-id <content_id>
      retransmissions-counted
      billing-action [ edr <edr_format> [ wait-until-flow-ends ] | egcdr | exclude-from-udrs | radius ] +
      flow idle-timeout <idle_timeout>
      end
Verifying your Configuration
To verify your configuration, in the Exec Mode, enter the following command:
show active-charging charging-action name <charging_action_name>
Configuring Tethering Detection Feature
This section describes how to configure the Tethering Detection feature to detect subscriber flows from PC devices tethered to mobile smartphones. For details on how this feature is implemented, see the Enhanced Charging Services Administration Guide.
To enable and configure the Tethering Detection feature, use the following configuration:
configure
  active-charging service <ecs_service_name>
     tethering-database [ os-signature <os_signature_db_file_name> | tac <tac_db_file_name> | ua-signature <ua_signature_db_file_name> ] +
     ruledef <tethering_detection_ruledef_name>
        tethering-detection { flow-not-tethered | flow-tethered }
        exit
     rulebase <rulebase_name>
        tethering-detection [ os-db-only | ua-db-only ]
        action priority <priority> ruledef <tethering_detection_ruledef_name> charging-action <charging_action_name>
        ...
        end
Upgrading Tethering Detection Databases
To upgrade the Tethering Detection feature databases, in the Exec mode, use the following CLI command:
upgrade tethering-detection database { all | os-signature | tac | ua-signature } [ -noconfirm ]
Sample Configurations
The following examples illustrate two different implementations of the Tethering Detection feature’s configuration.
•
The following type of configuration is suitable where ECS performance is critical and the operator wants to put in a flat charging plan in place for all the tethered traffic. In such a scenario, addition of a single new ruledef to the configuration suffices. Placing this ruledef at the highest priority in the rulebase will ensure all the tethered flows are charged as per the tariff plan for tethered traffic.
configure
  active-charging service ecs_service
     tethering-database
     ruledef tethered-traffic
        tethering-detection flow-tethered
        tcp any-match = TRUE
        exit
     ruledef ftp-pkts
        ftp any-match = TRUE
        exit
     ruledef http-pkts
        http any-match = TRUE
        exit
     ruledef tcp-pkts
        tcp any-match = TRUE
        exit
     ruledef ip-pkts
        ip any-match = TRUE
        exit
     ruledef http-port
        tcp either-port = 80
        rule-application routing
        exit
     ruledef ftp-port
        tcp either-port = 21
        rule-application routing
        exit
     charging-action premium
        content-id 1
        retransmissions-counted
        billing-action egcdr
        exit
     charging-action standard
        content-id 2
        retransmissions-counted
        billing-action egcdr
        exit
     rulebase consumer
        tethering-detection
        action priority 10 ruledef tethered-traffic charging-action premium
        action priority 20 ruledef ftp-pkts charging-action standard
        action priority 30 ruledef http-pkts charging-action standard
        action priority 40 ruledef tcp-pkts charging-action standard
        action priority 50 ruledef ip-pkts charging-action standard
        route priority 80 ruledef http-port analyzer http
        exit
     rulebase default
     end
•
The following type of configuration is suitable when operators want to apply differentiated charging to various flows that are found to be tethered. In this case, traffic that requires different charging action or content ID when it is tethered will be identified using two ruledefs, one with “flow-is-tethered = TRUE” option and another without this option. This configuration provides finer granularity of control but results in higher performance degradation because the rule matching tree size increases.
configure
  active-charging service ecs_service
     tethering-database
     ruledef ftp-pkts
        ftp any-match = TRUE
        exit
     ruledef ftp-pkts-tethered
        ftp any-match = TRUE
        tethering-detection flow-tethered
        exit
     ruledef http-pkts
        http any-match = TRUE
        exit
     ruledef http-pkts-tethered
        http any-match = TRUE
        tethering-detection flow-tethered
        exit
     ruledef tcp-pkts
        tcp any-match = TRUE
        exit
     ruledef tcp-pkts-tethered
        tcp any-match = TRUE
        tethering-detection flow-tethered
        exit
     ruledef ip-pkts
        ip any-match = TRUE
        exit
     ruledef ip-pkts-tethered
        ip any-match = TRUE
        tethering-detection flow-tethered
        exit
     ruledef http-port
        tcp either-port = 80
        rule-application routing
        exit
     ruledef ftp-port
        tcp either-port = 21
        rule-application routing
        exit
     charging-action premium-http
        content-id 10
        retransmissions-counted
        billing-action egcdr
        exit
     charging-action premium-ftp
        content-id 20
        retransmissions-counted
        billing-action egcdr
        exit
     charging-action premium
        content-id 1
        retransmissions-counted
        billing-action egcdr
        exit
     charging-action standard
        content-id 2
        retransmissions-counted
        billing-action egcdr
        exit
     rulebase consumer
        tethering-detection
        action priority 10 ruledef ftp-pkts-tethered charging-action premium-ftp
        action priority 20 ruledef ftp-pkts charging-action standard
        action priority 30 ruledef http-pkts-tethered charging-action premium-http
        action priority 40 ruledef http-pkts charging-action standard
        action priority 50 ruledef tcp-pkts-tethered charging-action premium
        action priority 60 ruledef tcp-pkts charging-action standard
        action priority 70 ruledef ip-pkts-tethered charging-action premium
        action priority 80 ruledef ip-pkts charging-action standard
        route priority 80 ruledef http-port analyzer http
        exit
     rulebase default
        end
EDR Module Configuration
Use the following configuration example to configure the EDR module:
configure
  context <context_name>
    edr-module active-charging-service [ charging | reporting ]
      file name <file_name> rotation volume <file_size_bytes> rotation time <file_complete_seconds> rotation num-records <records_number> storage-limit <storage_limit_bytes> headers reset-indicator edr-format-name trap-on-file-delete compression gzip file-sequence-number rulebase-seq-num
      cdr [ push-interval <interval> | remove-file-after-transfer | transfer-mode { pull | push primary { encrypted-url <enc_url> | url <url> } [ secondary { encrypted-secondary-url <enc_sec_url> | url <sec_url> } ] } + | use-harddisk ]
      end
Notes:
•
The <context_name> must be the context specified for accounting.
•
EDR type configuration is optional. The EDR types can be either charging or reporting. The charging keyword is the default setting.
For MUR reporting needs, use the reporting keyword for the EDR type.
•
The cdr use-harddisk command is only available on the ASR 5000 platform.
•
The cdr use-harddisk command specifies storing files on the hard disk. The reporting server will download these files through the SPIO interface on the SMC and will delete the files after successful retrieval.
•
The edr-format-name keyword must be configured to distinguish between different EDRs. The EDR file name must be configured in an accepted format so that the Offline Subscriber Reporting functionality can be used effectively. For information on this functionality and the EDR file name configuration recommendations, see the Cisco Mobility Unified Reporting System Online Help documentation.
•
The files will be compressed to save storage and transmission bandwidth.
•
For the PULL model, an external device like L-ESS is used to pull the EDR files from the chassis via SFTP. Whereas, for the PUSH model, the chassis is configured to push the files to the required destination.
Important: The chassis automatically creates /edr and /udr directories on the destined path on MUR server when you configure it to push the files.
•
The values recommended for rotation volume and rotation time keywords are 40 MB and 300 seconds respectively.
Important: In RHEL-based deployments, L-ESS is NOT required as the Enhanced Charging Services (ECS) module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.
The following is a sample EDR PUSH configuration.
configure
 context test
  edr-module active-charging-service reporting
    file name EDRFILE rotation num-records 10000 storage-limit 268435456 headers reset-indicator trap-on-file-delete compression gzip file-sequence-number rulebase-seq-num
    cdr transfer-mode push primary url sftp://root:nulink@10.4.72.54/inpilot-local/Ash_Test/starbi/server/data via local-context
    cdr push-interval 60
    cdr remove-file-after-transfer
    cdr use-harddisk
    end
The following is a sample EDR PULL configuration.
configure
 context local
  edr-module active-charging-service
    file name EDRFILE1 rotation time 300 rotation num-records 10000 storage-limit 268435456 headers reset-indicator trap-on-file-delete compression gzip file-sequence-number rulebase-seq-num
    cdr remove-file-after-transfer
    cdr use-harddisk
    end
Verifying your Configuration
To verify your configuration, in the Exec Mode, enter the following command:
show configuration context <context_name>
Pushing EDR/UDR Files Manually
To manually push EDR/UDR files to the configured L-ESS, in the Exec mode, enter the following command:
cdr-push { all | local-filename <file_name> }
Notes:
•
Before you can use this command, in the EDR/UDR Configuration Mode, the CDR transfer mode and file locations must be set to push.
•
<file_name> must be absolute path of the local file to push.
For more information on the cdr command, please refer to the Command Line Interface Reference.
Configuring EDR Download Permission
Use the following configuration example to configure EDR download permission:
configure
  context local
    administrator <administrator_id> password <password> ftp nocli
    end
Notes:
•
The user must be configured in the local context with administrative privileges to download and delete EDRs from the hard disk. The ftp nocli options restrict access to FTP only.
Configuring Bulkstats Schemas Using GUI
MUR provides a user interface to configure bulk statistics schemas on chassis / gateway via SSH and SFTP. The Client sends HTTP request to MUR to configure schemas on a particular gateway after providing inputs to the parameters needed for schema configuration. MUR server receives the HTTP request, generates a configuration file on the fly, sends the configuration file to the gateway via SFTP and loads it on to the gateway through SSH.
Important: In StarOS 10.0 and earlier releases, WEM is used to configure the bulkstats schemas on the chassis if user has deployed WEM. In case if WEM has not been deployed, then please contact local sales or service representative for obtaining the embedded bulkstats configuration file.
Important: In StarOS 11.0 and later releases, you can configure Bulkstat schemas only through the MUR GUI by selecting ADMIN > BULKSTATS menu.
Prior to configuring the bulkstats schemas, ensure that the following checks are performed:
•
The gateway must be running and active.
•
Enable SFTP and FTP services
For Solaris setup:
•
FTP must be enabled on the MUR server.
To enable the FTP daemon, use the following command:
/usr/sbin/svcadm/ enable ftp
To disable the FTP daemon, use the following command:
/usr/sbin/svcadm/ disable ftp
For RHEL setup:
•
FTP must be enabled on the MUR server.
To enable the FTP daemon, use the following command:
service vsftpd start
To disable the FTP daemon, use the following command:
service vsftpd stop
•
SSH version 2.0 key must be generated on the gateway. To generate the SSH version 2.0 key through the CLI, enter the following command:
configure
  context local
    ssh generate key type v2-rsa
    ssh generate key type v2-dsa
    end
•
Secure Shell (SSH) configuration mode must be enabled on the gateway. To enable the SSH configuration mode, enter the following command:
configure
  context local
    server sshd
    end
•
FTP/SFTP must be allowed on the gateway for the “SSH Username” that will be entered in the Bulkstat Schema Configuration screen. For example, if the username is staradmin and password is test then the following commands should be used to enable FTP/SFTP for staradmin user.
configure
  context local
    administrator staradmin password test ftp
    end
Important: The bulkstats report will be visible to users only when the schemas are configured successfully.
For information on how to configure the bulkstats schemas, see the Cisco Mobility Unified Reporting System Online Help documentation.
Supported Bulkstat Schemas
This section provides the list of bulk statistics schemas that are supported in MUR for reporting.
•
SS7RD
•
MME
•
SGW
•
MIPV6HA
•
PGW
•
IMSA
•
NAT_REALM
•
ASNGW
•
PORT
•
SGSN
•
MISC
•
CARD
•
MIPFA
•
GTPP
•
PHSGW
•
CSCFINTF
•
RADIUS
•
APN
•
CLOSEDRP
•
LAC
•
SGTP
•
IPPOOL
•
SCCP
•
GPRS
•
SS7LINK
•
CSCF
•
MAG
•
CONTEXT
•
SYSTEM
•
ECS
•
PHSPC
•
EGTPC
•
RP
•
PPP
•
MIPHA
•
PDG
•
GTPC
•
PDIF
•
IPSG
•
LMA
•
AAL2
•
ALCAP
•
ASNPC
•
BCMCS
•
CS_NW_RANAP
•
CS_NW_RTP
•
DCCA
•
DPCA
•
GTPU
•
HNBGW_HNBAP
•
HNBGW_RANAP
•
HNBGW_RTP
•
HNBGW_RUA
•
HNBGW_SCTP
•
LNS
•
PCC_POLICY
•
PCC_QUOTA
•
PCC_SERVICE
•
PCC_SP_ENDPT
•
PS_NW_RANAP
•
MVS
For more information on these bulkstats, refer to the Statistics and Counters Reference.
Supported SNMP Traps
The alarm generation feature aids in proactively monitoring the nodes and important resources of MUR. This feature also provides configuration interface for setting up thresholds and other key information related to critical resources. Alarms are generated when these thresholds are exceeded and various actions can be performed such as sending e-mail, syslog messages, Simple Network Management Protocol (SNMP) traps.
It is necessary to configure the SNMP manager or Network Node Manager (NNM) to receive these notifications. The SNMP server and SNMP event configurations can be made through the System menu in the Web-based MUR GUI.
Threshold values should be configured for the following event identifiers (event IDs):
•
CPU Usage - CPU — This alarm is generated when the CPU resource usage exceeds the preset threshold value.
•
Disk Usage - Disk — This alarm is generated when the disk usage exceeds the threshold.
•
Memory (Swap) Usage - Mem — This alarm is generated when the memory swap usage exceeds the threshold.
•
Unprocessed Files - UnprocFiles — This alarm is generated when the count of (HTTP-EDR/EDR/CF-EDR) files pending for getting parsed (in their respective directories), exceeds the threshold value.
•
Erroneous Files - ErrFiles — This alarm is generated whenever the count of invalid files exceeds the threshold value. The file is considered as invalid either due to missing headers or the file being corrupted.
•
Erroneous Records - ErrRecords — This alarm is generated when the number of erroneous records breaches the threshold. The EDR records are considered as erroneous when any of the fields are missing in the EDR or when an invalid data is present in a particular field.
In addition to this, MUR also supports AppStatus and TaskLag event identifiers; however, these are NOT configurable.
•
Application Status - AppStatus — This alarm is generated when the MUR application is started or stopped.
Important: Please note that the alarms are sent when Scheduling server/Apache server is started or stopped. However, in the case of Postgres server, alarms are sent only when it is started.
•
Task Lag - TaskLag — This alarm is generated when a particular script like normalization/aggregation takes more time than expected to complete the job.
The following scripts have been added for the Task Lag alarms, which play an important role in parsing EDR/HTTP-EDR/CF-EDR. Each of these scripts handle a specific task which is either part of aggregation or normalization.
Script
Default Value of Tasklag Time (in sec/min)
Edr Normalization
300 (5 min)
Http Edr Normalization
300 (5 min)
CF Edr Normalization
300 (5 min)
Protocol Summary
1800 (30 min)
Port Aggregation
1800 (30 min)
Subscriber Aggregation (minutely)
1800 (30 min)
Subscriber Aggregation (hourly)
3600 (60 min)
Flow Count
1800 (30 min)
Http Host Aggregation (minutely)
7200 (120 min)
Http Content Summary
7200 (120 min)
Http Host Aggregation (hourly)
7200 (120 min)
‌
Important: Please note that the user does not have the privilege to change these timings.
Note that these alarms (Unprocessed, Error Files, Error Records and TaskLag) can be triggered only for EDR, HTTP-EDR and CF-EDR files, and not for the bulkstats files.
Important: During a fresh installation of MUR, please note that there will no SNMP configurations available.
Important: Users with administrative privilege can only manage this configuration.
Important: The change in the configuration for enabling / disabling the alarm generation feature does not require a restart of the MUR application.
MUR also supports generation of KPI alarms through the GUI. KPI parser calculates the values of KPIs for which the alarms are configured through the GUI. The KPI parser uses the information stored by bulkstat parser in the database for KPI calculations and for sending alarms. This avoids reparsing of the same file and redundant connections to the DB.
KPI parser generates alarms only when the alarm functionality is enabled for MUR. The details of KPI alarms which are successfully sent can be seen through KPI Alarms Log under the System menu. For details on the log, see the Cisco Mobility Unified Reporting System Online Help documentation.
Important: Prior to configuring KPI alarms, you must ensure that the gateways and bulkstat schemas are configured and the bulkstats data are available.
For information on configuring the SNMP parameters, see the Cisco Mobility Unified Reporting System Online Help documentation.
For information on the SNMP traps and thresholds supported for MUR, see the Mobility Unified Reporting System MIB chapter of the SNMP MIB Reference.
 
 
Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883